In asymmetric encryption technology, each user generates a pair of keys known as a public key and a private key. The public key is widely disseminated and used by others to encrypt communications intended for the owner of the public key. Once the message has been encrypted with the public key, it can only be decrypted with the corresponding private key. This is the basis of public key encryption.
The problem with this technology is that the sender needs to have a way of guaranteeing that the public key used for encryption does indeed belong to the recipient. Otherwise, the sender could unintentionally encrypt a message that could only be decrypted by some mischievous third party. A method was therefore needed for users to be able to have a high degree of assurance that the owner of a public key was indeed the intended recipient.
Digital certificates were invented to solve this problem. A recognized certificate authority issues a certificate binding the public key of a subscriber to his real world identity. The certificate is digitally signed by the recognized issuing authority. A message is digitally signed in effect by encrypting it with a private key. The message can then only be decrypted with the corresponding public key, and provided the user has a high degree of trust in the certifying authority, he will then have assurance that the public key contained in the certificate does indeed belong to the user to whom it is bound.
Digital certificates generally follow the X.509 standard, developed by the International Standards Organization (ISO) and the Comité Consultatif Internationale Telegraphique et Telephonique (CCITT). These certificates create a binding between an entity's public key and its identity. Obtaining authentic copies of public key certificates is critical in deploying secure public key systems. Often a digital certificate is stored in a publicly accessible repository such as an LDAP or X.500 directory.
In practice, implementers of certificate revocation lists have discovered that they are difficult to manage because they can become very large and not usable by some certificate verifiers such as smartcards or mobile phones. Further, since these lists are issued only periodically, there is a time gap between when a certificate is revoked by its issuer and when it appears on a publicly available list of revoked certificates. Methods such as the online certificate status protocol have been developed as a means to make requests to validation services to determine whether a particular certificate is currently valid, however, this requires that a certificate verifier make at least two requests, one to obtain a copy of the certificate and another to obtain the current validity status of the certificate. Further requests may be required to obtain all certificates needed to construct a certificate chain that can be validated up to a trusted root held by the verifier. In many applications, in particular those where the verifier is a mobile phone, smartcard or other client devices that are relatively constrained with respect to storage capacity, processing power and communication bandwidth, the current solutions are not practical.
It will be apparent from the foregoing that prior certificate issuance and validation systems and methods are generally designed to allow a user to obtain a validated digital certificate, but are slow and cumbersome to the user under various circumstances.